Call Hold and Retrieve
For analog interfaces: Initiating call hold and retrieve:
|
■
|
Active calls can be put on-hold by pressing the phone's hook-flash button.
|
|
■
|
The party that initiates the hold is called the holding party; the other party is called the held party. |
|
■
|
After a successful hold, the holding party hears a dial tone (HELD_TONE defined in the device's Call Progress Tones file). |
|
■
|
Call retrieve can be done only by the holding party while the call is held and active.
|
|
■
|
The holding party performs the retrieve by pressing the telephone's hook-flash button.
|
|
■
|
After a successful retrieve, the voice is connected again. |
|
■
|
Hold is done by sending a re-INVITE message with IP address 0.0.0.0 or a=sendonly in the SDP, according to the HoldFormat parameter.
|
For analog interfaces: Receiving Hold/Retrieve:
|
■
|
When an active call receives a re-INVITE message with IP address 0.0.0.0 or ‘inactive’ string in SDP, the device stops sending RTP and plays a local held tone.
|
|
■
|
When an active call receives a re-INVITE message with the ‘sendonly’ string in SDP, the device stops sending RTP and listens to the remote party. In this mode, it is expected that music on-hold (or any other hold tone) is played (over IP) by the remote party.
|
You can also configure the device to keep a call on-hold for a user-defined time after which the call is disconnected, using the [HeldTimeout] parameter.
When the Tel side puts the call on hold (hookflash), the device plays a dial tone to the Tel side (dial tone timeout starts according to the 'Dial Tone Duration' parameter, which is 16 sec. by default), expecting the Tel side to do some action (e.g., make another call, conferencing, or call transfer). If the 'Dial Tone Duration' parameter expires as no DTMF digits were collected (i.e., Tel side did nothing), the device plays a congestion tone to the Tel side (and if the Tel side goes on-hook, the phone rings and if the Tel side then goes off-hook, the IP side is retrieved).
The device also supports "double call hold" for FXS interfaces where the called party, which has been placed on-hold by the calling party, can then place the calling party on hold as well and make a call to another destination. The flowchart below provides an example of this type of call hold:
The flowchart above describes the following "double" call-hold scenario for analog interfaces:
|
1.
|
A calls B and establishes a voice path.
|
|
2.
|
A places B on hold; A hears a dial tone and B hears a held tone.
|
|
3.
|
A calls C and establishes a voice path.
|
|
4.
|
B places A on hold; B hears a dial tone.
|
|
5.
|
B calls D and establishes a voice path.
|
|
6.
|
A ends call with C; A hears a held tone.
|
|
8.
|
B retrieves call with A.
|
For analog interfaces:
|
●
|
If a party that is placed on hold (e.g., B in the above example) is called by another party (e.g., D), then the on-hold party receives a call waiting tone instead of the held tone.
|
|
●
|
While in a Double Hold state, placing the phone on-hook disconnects both calls (i.e. call transfer is not performed).
|
|
●
|
You can enable the device to handle incoming re-INVITE messages with 'a=sendonly' in the SDP, in the same way as if 'a=inactive' is received in the SDP. This is configured using the [SIPHoldBehavior] parameter. When enabled, the device plays a held tone to the Tel phone and responds with a 200 OK containing 'a=recvonly' in the SDP.
|